-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Allow filtering by multiple tags [FC-0040] #945
feat: Allow filtering by multiple tags [FC-0040] #945
Conversation
Thanks for the pull request, @bradenmacdonald! Please note that it may take us up to several weeks or months to complete a review and merge your PR. Feel free to add as much of the following information to the ticket as you can:
All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here. Please let us know once your PR is ready for our review and all tests are green. |
bb13328
to
71024e9
Compare
Hi @bradenmacdonald! If you have this ready before EOD Monday, could you ping me so I can include these changes in the sandbox? Thanks! |
71024e9
to
e1abaf7
Compare
@rpenido Sure! |
8b26071
to
308b5aa
Compare
@rpenido This is ready! At least, ready enough for the sandbox. It still needs a lot of refinement before it's ready for code review. For your convenience, I merged it with your sandbox branch on a new branch called |
Ack. The current sandbox is running based on this branch. Tomorrow, I will take a look to fix the breadcrumbs and see if there are more things to fix. Thank you @bradenmacdonald ! Edit: The tag filter is not working in the sandbox:
We probably need to fix this while creating the index. |
@rpenido Yeah, I forgot about the edx-platform changes required :/ I pinged you about it on MatterMost. It just needs a few lines of code changed and the index regenerated: openedx/edx-platform#34534 |
996fd2d
to
2e2cdf7
Compare
756aaa9
to
bc7943c
Compare
@rpenido This is ready for review. |
@@ -67,17 +67,9 @@ describe('<SearchModal />', () => { | |||
expect(await findByText('Start searching to find content')).toBeInTheDocument(); | |||
}); | |||
|
|||
it('should render the spinner while the config is loading', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The spinner is no longer needed. Now the search UI displays immediately without waiting for the connection details, which is a better user experience.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #945 +/- ##
=========================================
Coverage ? 92.00%
=========================================
Files ? 636
Lines ? 11273
Branches ? 2436
=========================================
Hits ? 10372
Misses ? 868
Partials ? 33 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @bradenmacdonald !
I read through the code and only have some nits and syntax suggestions. Good work here!
While testing, I found some errors while typing in the tag search input.
The failed request is bellow:
curl 'http://meilisearch.local.edly.io:7700/indexes/tutor_studio_content/search' --compressed -X POST -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:124.0) Gecko/20100101 Firefox/124.0' -H 'Accept: */*' -H 'Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.5,en;q=0.3' -H 'Accept-Encoding: gzip, deflate' -H 'Referer: http://apps.local.edly.io:2001/' -H 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhcGlLZXlVaWQiOiJhOGE1NGM2Ny0zZTkwLTQ2YmItYWMzMC03NWFkZDZiOWJhMTkiLCJzZWFyY2hSdWxlcyI6eyJ0dXRvcl9zdHVkaW9fY29udGVudCI6e319LCJleHAiOjE3MTQwNTEzNzV9.hRsgsRseHHV3KuX65VUTdlDmZurEx8orBwY-pp22jjM' -H 'Content-Type: application/json' -H 'X-Meilisearch-Client: Meilisearch JavaScript (v0.38.0)' -H 'Origin: http://apps.local.edly.io:2001' -H 'Connection: keep-alive' --data-raw '{"q":"e","filter":[],"attributesToSearchOn":["tags.taxonomy","tags.level0","tags.level1","tags.level2","tags.level3"],"attributesToRetrieve":["tags"],"limit":1000}'
And the response:
{"message":"Attribute `tags.level3` is not searchable. Available searchable attributes are: `block_id, content, content.background_image_description, content.capa_content, content.html_content, content.item_0_display_name, content.item_0_image_description, content.item_1_display_name, content.item_1_image_description, content.item_2_display_name, content.item_2_image_description, content.item_3_display_name, content.item_3_image_description, content.item_4_display_name, content.item_4_image_description, content.problem_types, content.prompt, content.question_text, content.title, content.zone_0_description, content.zone_0_display_name, content.zone_1_description, content.zone_1_display_name, content.zone_2_description, content.zone_2_display_name, display_name, tags, tags.level0, tags.level1, tags.level2, tags.taxonomy`.","code":"invalid_search_attributes_to_search_on","type":"invalid_request","link":"https://docs.meilisearch.com/errors#invalid_search_attributes_to_search_on"}
I find it odd because it is working (for me) in the sandbox without adding the tags.level*
to the searchable fields. Also, @yusuf-musleh had the same error in the sandbox (and couldn't reproduce it also).
I suspect that that error occurs only if you don't actually have any level3 tags in your search index. In other words, it's not so much the setting, but it's about what content/tags you have. I will try deleting all my level3 tags from the database and see if I can reproduce it. |
Co-authored-by: Rômulo Penido <[email protected]>
66e4122
to
2fab892
Compare
@xitij2000 This is ready for your review and (once approved) merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code seems to be working as expected and I don't have any other specific feedback, but I did notice that the meilisearch API is being directly used.
I don't know about meilisearch to know if this is a problem, but doesn't exposing it directly mean that anyone can run queries against the server and get access to data that's been indexed but shouldn't be accessible to them?
@xitij2000 Thanks! Good question, but the answer is no - we give each user a restricted API key that only allows them to search content that they're allowed to see. You can see openedx/edx-platform#34471 if you're interested in the details. This approach is much faster since the CMS/LMS isn't needed to act as a proxy for the search engine, and it reduces load on the edxapp django IDA. |
@xitij2000 Could you please merge this then? :) |
@bradenmacdonald 🎉 Your pull request was merged! Please take a moment to answer a two question survey so we can improve your experience in the future. |
Description
As of #918 , the content search only allows filtering the results by one tag at a time, which is a limitation of Instantsearch.
So with this PR, I have replaced our usage of Instantsearch + instant-meilisearch with just direct usage of Meilisearch. Not only does this simplify the code and make our MFE bundle size smaller, but it allows us much more control over how the tags filtering works, so that I can implement searching by multiple tags.
(Trying to modify Instantsearch to do that was too difficult, given the complexity of its codebase).
Related ticket: openedx/modular-learning#201
Before
After
TODO
Testing instructions
./manage.py cms reindex_studio --experimental
in your CMS container.Other information
Private ref: FAL-3704
Depends on: #918